<html>
<head><meta charset="utf-8"><title>more broken clocks · t-libs · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/index.html">t-libs</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html">more broken clocks</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="235549710"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235549710" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235549710">(Apr 21 2021 at 17:27)</a>:</h4>
<p><a href="https://github.com/rust-lang/rust/issues/80674">#80674</a> another case of time going backwards. Possibly due to lying hypervisor + old kernel + not-quite-recent CPU (2012 vintage).<br>
Is this a strong enough case to extend the mutex hammer to x86_64 linux which so far has been exempt from it?<br>
Or is advising users to change their clock source or fixing the hypervisor sufficient? At least linux provides options here...</p>



<a name="235550467"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235550467" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235550467">(Apr 21 2021 at 17:32)</a>:</h4>
<p>All of the issues with the clock going backward are usually due to hardware bugs.</p>



<a name="235550575"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235550575" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235550575">(Apr 21 2021 at 17:32)</a>:</h4>
<p>Or virtual hardware. But I'm starting to wonder whether the right answer is to panic on hardware bugs, or whether we can be more robust against them...</p>



<a name="235550659"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235550659" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235550659">(Apr 21 2021 at 17:33)</a>:</h4>
<p>That said, I also wonder if we could fix the <em>kernel</em>'s implementation of MONOTONIC...</p>



<a name="235550679"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235550679" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235550679">(Apr 21 2021 at 17:33)</a>:</h4>
<p>Rather than having to work around it in Rust.</p>



<a name="235550825"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235550825" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235550825">(Apr 21 2021 at 17:34)</a>:</h4>
<p>It <em>really</em> should be the kernel's job to fix this. After all, they are the ones promising <em>monotonic</em> time.</p>



<a name="235550919"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235550919" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235550919">(Apr 21 2021 at 17:34)</a>:</h4>
<p>rename the constant to MONOTONICISH</p>



<a name="235550955"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235550955" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235550955">(Apr 21 2021 at 17:35)</a>:</h4>
<p><span class="user-mention silent" data-user-id="143274">Amanieu</span> <a href="#narrow/stream/219381-t-libs/topic/more.20broken.20clocks/near/235550825">said</a>:</p>
<blockquote>
<p>It <em>really</em> should be the kernel's job to fix this. After all, they are the ones promising <em>monotonic</em> time.</p>
</blockquote>
<p>Yeah, I agree.</p>



<a name="235551045"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235551045" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235551045">(Apr 21 2021 at 17:35)</a>:</h4>
<p>The kernel _does_ fix this by default<br>
<a href="https://github.com/torvalds/linux/blob/8bb495e3f02401ee6f76d1b1d77f3ac9f079e376/arch/x86/kernel/pvclock.c#L77-L100">https://github.com/torvalds/linux/blob/8bb495e3f02401ee6f76d1b1d77f3ac9f079e376/arch/x86/kernel/pvclock.c#L77-L100</a></p>
<p>Except for cases where the hardware/vm promises that it's really reliable... the issue is implementations that promise this and then break their promise</p>



<a name="235551373"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235551373" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235551373">(Apr 21 2021 at 17:37)</a>:</h4>
<p>And we're dealing with some old frankenkernel in this particular case, so even if a current kernel implemented more defenses it wouldn't help.</p>



<a name="235552291"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235552291" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235552291">(Apr 21 2021 at 17:44)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/219381-t-libs/topic/more.20broken.20clocks/near/235550659">said</a>:</p>
<blockquote>
<p>That said, I also wonder if we could fix the <em>kernel</em>'s implementation of MONOTONIC...</p>
</blockquote>
<p>this seems like a loosing battle, since presumably there is more than one kernel to worry about</p>



<a name="235552798"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235552798" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235552798">(Apr 21 2021 at 17:47)</a>:</h4>
<p>Well, we don't trust all kernels. E.g. linux is trusted conditional on it being x86(64). windows is never trusted. osx is always trusted...</p>



<a name="235553239"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235553239" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235553239">(Apr 21 2021 at 17:50)</a>:</h4>
<p>Is there a kernel option to make it not trust the kvm clock?</p>



<a name="235553300"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235553300" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235553300">(Apr 21 2021 at 17:50)</a>:</h4>
<p>Basically to make it ignore <code>PVCLOCK_TSC_STABLE_BIT</code>.</p>



<a name="235553393"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235553393" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235553393">(Apr 21 2021 at 17:51)</a>:</h4>
<p>I'm not sure, but you can tell it to pick a different clock source</p>



<a name="235553551"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235553551" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235553551">(Apr 21 2021 at 17:52)</a>:</h4>
<p>From a quick grep, apparently not.</p>



<a name="235553564"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235553564" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235553564">(Apr 21 2021 at 17:52)</a>:</h4>
<p><span class="user-mention silent" data-user-id="220273">Jane Lusby</span> <a href="#narrow/stream/219381-t-libs/topic/more.20broken.20clocks/near/235552291">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/219381-t-libs/topic/more.20broken.20clocks/near/235550659">said</a>:</p>
<blockquote>
<p>That said, I also wonder if we could fix the <em>kernel</em>'s implementation of MONOTONIC...</p>
</blockquote>
<p>this seems like a loosing battle, since presumably there is more than one kernel to worry about</p>
</blockquote>
<p>I think the distinction would be that if a kernel promises "monotonic" we could trust the kernel, while if we don't have such a promise we need to synthesize one ourselves.</p>



<a name="235553678"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235553678" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235553678">(Apr 21 2021 at 17:53)</a>:</h4>
<p>did misunderstand what you meant when you said "fix the kernel's implementation"? I assumed you meant patch the kernel upstream somehow</p>



<a name="235554243"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235554243" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235554243">(Apr 21 2021 at 17:57)</a>:</h4>
<p>There's a <code>clearcpuid</code> boot flag and KVM flags are communicated via cpuid, of sorts? So maybe it can be blocked.</p>



<a name="235554427"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235554427" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235554427">(Apr 21 2021 at 17:58)</a>:</h4>
<p><span class="user-mention silent" data-user-id="220273">Jane Lusby</span> <a href="#narrow/stream/219381-t-libs/topic/more.20broken.20clocks/near/235553678">said</a>:</p>
<blockquote>
<p>did misunderstand what you meant when you said "fix the kernel's implementation"? I assumed you meant patch the kernel upstream somehow</p>
</blockquote>
<p>That's exactly what I meant. If CLOCK_MONOTONIC goes backwards, that's a bug in the Linux kernel.</p>



<a name="235554471"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235554471" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235554471">(Apr 21 2021 at 17:59)</a>:</h4>
<p>According to the documentation:</p>
<blockquote>
<p>All CLOCK_MONOTONIC variants guarantee that the  time  returned  by consecutive calls will not go backwards, but successive calls may—depending on the architecture—return identical (not-increased) time values.</p>
</blockquote>



<a name="235554533"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235554533" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235554533">(Apr 21 2021 at 18:00)</a>:</h4>
<p>yeah but it looks like they are just dealing with the same problem as we have, with an upstream clock lying about its properties (hardware or vm or whatever)</p>



<a name="235554639"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235554639" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235554639">(Apr 21 2021 at 18:00)</a>:</h4>
<p>Sure, but perhaps the kernel should do the same thing we do, and try to detect if the clock goes backwards.</p>



<a name="235554677"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235554677" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235554677">(Apr 21 2021 at 18:00)</a>:</h4>
<p>But yeah, ultimately, if the hardware or VM says "I'm monotonic" and then isn't, that's a hardware/VM bug.</p>



<a name="235554731"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235554731" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235554731">(Apr 21 2021 at 18:01)</a>:</h4>
<p>The kernel should work around that if it can, but given the performance sensitivity of getting the time, it may or may not be able to.</p>



<a name="235554798"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235554798" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235554798">(Apr 21 2021 at 18:01)</a>:</h4>
<p>the kernel does have the same workaround as we have</p>



<a name="235554799"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235554799" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Steven Fackler <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235554799">(Apr 21 2021 at 18:01)</a>:</h4>
<p>would the kernel be able to do anything about that if gettime is going through the VDSO?</p>



<a name="235554830"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235554830" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235554830">(Apr 21 2021 at 18:01)</a>:</h4>
<p>and just like us they disable it on some trusted sources</p>



<a name="235554972"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235554972" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235554972">(Apr 21 2021 at 18:02)</a>:</h4>
<p><span class="user-mention" data-user-id="310399">@Mara</span> In some cases, the kernel may have enough information to detect that the sources are lying about being trustable.</p>



<a name="235554991"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235554991" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235554991">(Apr 21 2021 at 18:02)</a>:</h4>
<p><span class="user-mention" data-user-id="243558">@Steven Fackler</span> yeah that's an interesting question. the code in the vdso wouldn't have write access to anything in kernel memory, but it could do it in a per-process way.</p>



<a name="235554993"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235554993" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235554993">(Apr 21 2021 at 18:02)</a>:</h4>
<p>the kernel knows more than we do though. it can look at cpuids, choose different clock sources and can afford to spend a few microseconds on a calibration loop during boot time.</p>



<a name="235555054"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235555054" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235555054">(Apr 21 2021 at 18:03)</a>:</h4>
<p>For instance, "hmmm, the bit is set to say it's really monotonic, but the hardware ID says it's this buggy VM, so, no".</p>



<a name="235555152"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235555152" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235555152">(Apr 21 2021 at 18:03)</a>:</h4>
<p>yeah. computers are hard :(</p>



<a name="235555175"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235555175" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235555175">(Apr 21 2021 at 18:04)</a>:</h4>
<p>If we can get more information about the buggy environment people are using that lets monotonic go backwards, we might be able to get the Linux kernel to denylist that environment's "I'm monotonic!" flag and say "no, you're not".</p>



<a name="235555607"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235555607" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235555607">(Apr 21 2021 at 18:06)</a>:</h4>
<p>checking whether the time goes backwards on every tsc call is exactly as expensive/reliable as forcing it to be monotonic. either you do it thread/core-local in which case it's not 100% reliable or you do it globally and then you suffer cache misses.<br>
the only way to be cheaper than that is trusting the various hardware/vm flags that say "I promise to be monotic"</p>



<a name="235555803"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235555803" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235555803">(Apr 21 2021 at 18:07)</a>:</h4>
<p>i was about to link <a href="https://github.com/rust-lang/rust/issues/83093">#83093</a>, but that's your PR :)</p>



<a name="235556024"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235556024" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235556024">(Apr 21 2021 at 18:08)</a>:</h4>
<p>once that's in place we can probably just enable that on all x86 platforms</p>



<a name="235556259"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235556259" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235556259">(Apr 21 2021 at 18:09)</a>:</h4>
<p>ah that pr already does that</p>



<a name="235556261"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235556261" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235556261">(Apr 21 2021 at 18:09)</a>:</h4>
<p>well, it might still suck for people who want to do really fine-grained measurements. it gets more expensive the more parallelism you have. while tsc in itself is constant overhead no matter how many threads.</p>



<a name="235556290"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235556290" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235556290">(Apr 21 2021 at 18:09)</a>:</h4>
<p>no, it doesn't</p>



<a name="235556303"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235556303" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235556303">(Apr 21 2021 at 18:09)</a>:</h4>
<p>I still think we shouldn't add the overhead to <em>all</em> Linux platforms, given that Linux promises that monotonic is monotonic.</p>



<a name="235556355"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235556355" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235556355">(Apr 21 2021 at 18:10)</a>:</h4>
<p>oh i'm misreading it</p>



<a name="235556405"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235556405" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235556405">(Apr 21 2021 at 18:10)</a>:</h4>
<p><a href="https://github.com/rust-lang/rust/pull/83093/files#diff-3183738c82f747fd92bb573712073aa384b16e14d154bf2df18f41077edc31cbR318-R320">https://github.com/rust-lang/rust/pull/83093/files#diff-3183738c82f747fd92bb573712073aa384b16e14d154bf2df18f41077edc31cbR318-R320</a><br>
OS_MONOTONIC is the old check, so x86 would still be trusted.</p>



<a name="235556734"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235556734" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235556734">(Apr 21 2021 at 18:12)</a>:</h4>
<blockquote>
<p>I still think we shouldn't add the overhead to all Linux platforms, given that Linux promises that monotonic is monotonic.</p>
</blockquote>
<p>Well, we could add more checks to the standard lib too. E.g. probe for virtualization or the used clock source. It only has to be done once.</p>



<a name="235556858"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235556858" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235556858">(Apr 21 2021 at 18:13)</a>:</h4>
<p>Or we could tell users to report to their OS vendor (for enterprisy kernels) or upstream if they're recent?</p>



<a name="235557240"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235557240" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235557240">(Apr 21 2021 at 18:16)</a>:</h4>
<p>The problem is that in <a href="https://github.com/rust-lang/rust/issues/80674">#80674</a> the buggy kernel is actually the Linux kernel running as the hypervisor, for which we can't easily get a version number from inside the VM.</p>



<a name="235558110"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235558110" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235558110">(Apr 21 2021 at 18:22)</a>:</h4>
<p>Maybe we could provide an environment to override our <code>actually_monotonic()</code>?</p>
<p><code>MY_CLOCK_IS_RIGHT=twice_a_day</code> vs. <code>MY_CLOCK_IS_RIGHT=always</code></p>



<a name="235558200"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235558200" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235558200">(Apr 21 2021 at 18:22)</a>:</h4>
<p>that'd help people with broken hardware without slowing everyone else down.</p>



<a name="235559326"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235559326" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235559326">(Apr 21 2021 at 18:31)</a>:</h4>
<p>If we can check that variable once and cache that check, such that we add ~0 overhead for people who don't set the variable, that sounds entirely reasonable.</p>



<a name="235559608"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235559608" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235559608">(Apr 21 2021 at 18:33)</a>:</h4>
<p><span class="user-mention" data-user-id="330154">@The 8472</span> You said "broken hypervisors on old CPUs without nonstop_tsc". Do such hypervisors pass enough information through that we can detect the flag on the CPU, or is the hypervisor setting that CPU flag without actually having the CPU flag set on the host CPU?</p>



<a name="235559743"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235559743" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235559743">(Apr 21 2021 at 18:34)</a>:</h4>
<p>Perhaps there's another way we can detect those old buggy hypervisors, via some of the virtual-BIOS-advertised information that has changed in more recent kernels.</p>



<a name="235560896"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235560896" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235560896">(Apr 21 2021 at 18:43)</a>:</h4>
<p>Some googling tells me that the CPU (E5-2690 v3) itself should have nonstop_tsc support, but the guest cpuinfo didn't show it. So the question is whether the hypervisor didn't pass that through or the kernel is too old to recognize it.</p>



<a name="235561038"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235561038" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235561038">(Apr 21 2021 at 18:44)</a>:</h4>
<p>Ah, well, another possible source of confusion... the user posted stats from a different system which may not be the initial system on which he encountered the bug. So I wouldn't trust this data too much yet.</p>



<a name="235563282"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235563282" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235563282">(Apr 21 2021 at 19:00)</a>:</h4>
<p>NONSTOP_TSC predates 3.10, so the kernel should have recognized it <br>
<a href="https://github.com/torvalds/linux/commit/40fb17152c50a69dc304dd632131c2f41281ce44">https://github.com/torvalds/linux/commit/40fb17152c50a69dc304dd632131c2f41281ce44</a><br>
<a href="https://openbenchmarking.org/s/2%20x%20Intel%20Xeon%20E5-2690%20v3">https://openbenchmarking.org/s/2%20x%20Intel%20Xeon%20E5-2690%20v3</a></p>



<a name="235563775"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235563775" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235563775">(Apr 21 2021 at 19:02)</a>:</h4>
<p>If the guest cpuinfo didn't pass through nonstop_tsc, why did the kernel assume the TSC was usable?</p>



<a name="235563790"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235563790" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235563790">(Apr 21 2021 at 19:02)</a>:</h4>
<p>/me is confused.</p>



<a name="235565342"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235565342" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235565342">(Apr 21 2021 at 19:12)</a>:</h4>
<p>It used <code>kvm_clock</code>, for which the host can also promise that it is reliable.</p>



<a name="235592557"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235592557" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235592557">(Apr 21 2021 at 22:33)</a>:</h4>
<p>I've seen clocks going back on x86_64 linux many times, incl. bare recent hardware from the certain major blue-coloured vendor, and on recent kernels.</p>



<a name="235592650"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235592650" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235592650">(Apr 21 2021 at 22:34)</a>:</h4>
<p>To the point that all of the code computing timestamp deltas at my current employer manually handles this possiblity.</p>



<a name="235593391"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235593391" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235593391">(Apr 21 2021 at 22:41)</a>:</h4>
<p>to give an estimate of how common this is on x86_64, AFAIR we'd observe a crash related to this ~once a month for every 50 processes (with 4 processes/server), where within each process the <code>duration_since</code> or <code>elapsed</code> are called with timestamps that should be approx 30ms apart, about 30 times per second.</p>



<a name="235593898"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235593898" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235593898">(Apr 21 2021 at 22:46)</a>:</h4>
<p>I can try digging up cpuinfo and similar info from the hardware on which this used to happen if anybody cares.</p>



<a name="235599144"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235599144" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235599144">(Apr 21 2021 at 23:46)</a>:</h4>
<p><span class="user-mention" data-user-id="123586">@nagisa</span> It would be helpful to get <code>/proc/cpuinfo</code>, <code>dmesg</code>, and <code>/sys/devices/system/clocksource/clocksource0/current_clocksource</code> from a bare-metal system that has that issue.</p>



<a name="235653908"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235653908" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235653908">(Apr 22 2021 at 10:35)</a>:</h4>
<p>One of the machines that had this issue surface 6 months ago:</p>
<div class="codehilite"><pre><span></span><code>$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
</code></pre></div>
<p><a href="https://paste.rs/9UL">procinfo</a>, <a href="https://paste.rs/EHh">dmesg</a>. <a href="https://paste.rs/AEn">another procinfo</a> from a machine we've seen this happen a year ago. Same <code>clocksource</code>. I believe at the time we were using the LTS kernel used in then current ubuntu LTS release  (4.4)</p>
<p>Now that I checked both of these are sandy bridges and, in fact, the one of them is the same chip as from the original issue report. I do recall us finding, at the time, a number of issue reports around the <code>redhat</code>'s bugtracker as well as at <a href="https://stackoverflow.com/questions/3657289/linux-clock-gettimeclock-monotonic-strange-non-monotonic-behavior">other places</a> about <code>CLOCK_MONOTONIC</code> not being actually monotonic.</p>



<a name="235657443"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235657443" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235657443">(Apr 22 2021 at 11:10)</a>:</h4>
<p>Sadly the fleet I have access to is not extensive enough to say whether this is a sandybridge specific issue or not.</p>



<a name="235704568"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235704568" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> cuviper <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235704568">(Apr 22 2021 at 16:09)</a>:</h4>
<p>hmm, my i7-7700K and Ryzen 7 3800X both say <code>tsc</code> for that on Fedora 34</p>



<a name="235704675"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235704675" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> cuviper <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235704675">(Apr 22 2021 at 16:09)</a>:</h4>
<p><code>available_clocksource</code> has <code>tsc hpet acpi_pm</code> -- do you know where this gets selected?</p>



<a name="235704886"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235704886" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> cuviper <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235704886">(Apr 22 2021 at 16:11)</a>:</h4>
<p>actually, Intel tsc has been stable for a while now, no?</p>



<a name="235705110"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235705110" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> cuviper <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235705110">(Apr 22 2021 at 16:12)</a>:</h4>
<p>ah, dmesg shows <code>clocksource: Switched to clocksource tsc</code>, so I guess that is detected</p>



<a name="235707602"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235707602" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235707602">(Apr 22 2021 at 16:30)</a>:</h4>
<p>it checks a few cpuid flags and then does a calibration loop against one of the other timers and if all that passes selects tsc as default, if not it'll pick some of the other ones. there also are boot options to specify a preference. you can also explicitly mark tsc as unreliable at boot.</p>



<a name="235742042"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235742042" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235742042">(Apr 22 2021 at 20:24)</a>:</h4>
<p><a href="https://github.com/rust-lang/rust/issues/84448">#84448</a></p>



<a name="235746058"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235746058" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235746058">(Apr 22 2021 at 20:56)</a>:</h4>
<p>I would use this in production software if it wasn't an environment variable tbh.</p>



<a name="235746165"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235746165" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235746165">(Apr 22 2021 at 20:57)</a>:</h4>
<p>As is there's risk that setting the envvar like this would break in case something somehow read the clock before main.</p>



<a name="235746230"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235746230" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235746230">(Apr 22 2021 at 20:57)</a>:</h4>
<p>And so adding calls to read the clock in any code then could become a breaking/observable change.</p>



<a name="235746448"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235746448" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235746448">(Apr 22 2021 at 20:59)</a>:</h4>
<p>I will write these down as pr comments once I'm back at computer if I don't forget.</p>



<a name="235748076"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235748076" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235748076">(Apr 22 2021 at 21:05)</a>:</h4>
<p>setting an environment variable through your... environment is more difficult than setting it in main?</p>



<a name="235749008"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235749008" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235749008">(Apr 22 2021 at 21:10)</a>:</h4>
<p>oh I guess, you mean to just put in a build so it's always the default no matter where it's deployed. Yeah, that's not really how I thought about it. It's meant for known-bad hardware.</p>



<a name="235761866"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235761866" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235761866">(Apr 22 2021 at 23:02)</a>:</h4>
<p>Should we go as far as mentioning this in the panic message for <code>Instant</code> subtraction?</p>



<a name="235763138"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235763138" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235763138">(Apr 22 2021 at 23:16)</a>:</h4>
<p>I have added a documentation section on <code>Instant</code> and linked there from <code>elapsed()#Panics</code></p>



<a name="235764730"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/more%20broken%20clocks/near/235764730" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/more.20broken.20clocks.html#235764730">(Apr 22 2021 at 23:35)</a>:</h4>
<p><span class="user-mention silent" data-user-id="143274">Amanieu</span> <a href="#narrow/stream/219381-t-libs/topic/more.20broken.20clocks/near/235761866">said</a>:</p>
<blockquote>
<p>Should we go as far as mentioning this in the panic message for <code>Instant</code> subtraction?</p>
</blockquote>
<p>I think we should.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>